The Constrained Application Protocol (CoAP) is a specialized web transfer protocol designed for machine-to-machine (M2M) applications in constrained nodes and constrained networks. In the present context, the term “constrained” refers to limitations in CPU, memory, and power resources that are inherent to devices which are expected to be used for the Internet-of-Things (IoT). CoAP provides a request-response based architecture between endpoints, where the communication is typically performed between a CoAP Server and one or more CoAP Clients over the User Datagram Protocol (UDP).
CoAP is designed to easily work along with the Hypertext Transfer Protocol (HTTP) for integration with the current Web, while adding additional features such as multicast support, very low overhead, and simplicity for constrained environments. One of the available extensions to CoAP enables CoAP clients to observe resources from CoAP servers, i.e. it enables CoAP servers to notify CoAP clients. Such an extension enables server-initiated communication in constrained networks using CoAP.
Open Mobile Alliance Device Management (OMA-DM) Lightweight is a light and compact device management protocol designed for M2M networks, which includes device management and service enablement for lightweight M2M (LWM2M) devices. Further details of OMA-DM LW can be found in the “Lightweight Machine to Machine Technical Specification”, Candidate Version 1.0, 10 Dec. 2013, OMA-TS-LightweightM2M-V1_0-20131210-C.
Being designed for constrained networks, OMA-DM LW can run CoAP over both UDP and Short Message Service (SMS) bindings. This enables OMA-DM LW to be applicable with any constrained device or network using CoAP.
LWM2M defines three logical components:                LWM2M Server: manages LWM2M Clients.        LWM2M Client: contains various Objects with different Resources. It executes commands sent by the LWM2M Servers and then reports the results for device management and the service enablement.        LWM2M Bootstrap Server: used during bootstrap procedures, and takes care of the initial configuration of the LWM2M Clients.        
In addition, four interfaces are defined between these logical components:                Client Registration: enables LWM2M Clients to register with one or more LWM2M servers after bootstrapping of the device.        Bootstrap: used by the LWM2M Bootstrap Server to set initial configurations on the LWM2M Client.        Device Management and Service Enablement: allows the LWM2M Server to perform the device management and M2M service enablement. Over this interface, the LWM2M Server can send operations to the LWM2M Client and obtain the response of the operations from the LWM2M Client. Both services and new management routines are set using Objects with the appropriate executable privileges set.        Information Reporting: this interface allows the LWM2M Client to report resource information to the LWM2M Server in the form of Notifications. Information Reporting can be triggered periodically using an Observe message, or by events, depending of the logic in the client.        
The relationship between the various operations performed over these interfaces, and their uplink or downlink direction, are listed in Table 1 below:
TABLE 1InterfaceDirectionOperationBootstrapUplinkRequest BootstrapBootstrapDownlinkWrite, DeleteClient RegistrationUplinkRegister, Update, De-RegisterDevice Management andDownlinkCreate, Read, Write, Delete,Service EnablementExecute, Write Attributes,DiscoverInformation ReportingDownlinkObserve, Cancel ObservationInformation ReportingUplinkNotify
After a bootstrap procedure has been completed, an LWM2M Client registers with an LWM2M Server following a client registration interface flow, as defined in the LWM2M Technical Specifications. The registration is performed when the LWM2M Client sends a “Register” operation to the LWM2M Server.
Periodically or based on certain events within the LWM2M Client or initiated by the LWM2M Server, the LWM2M Client updates its registration information with the LWM2M Server. The default value of updating the registration is every 86400 seconds (24 hours).
Referring to FIG. 1, the result of the above is that a number of client devices 101 to 10n communicate directly with a server device 20. The process of client devices 101 to 10n registering and updating their information so frequently can be very cumbersome for some server devices 20. In many situations where server devices 20 will be handling thousands or even millions of client devices 10, the process of registration and updating the registration can be extremely time consuming and costly.
Moreover, the management of a large number of client devices 101 to 10n can be a difficult task for the administrator (or administrators) of a server device 20, for example when having to keep track of the client devices 10 that join or leave a network.